Open Source, EU Funding and Agile Methods

This paper walks through different aspects of agility within the open-source PyPy project. Agility has played a key role from the beginning. The PyPy project started from some mails between a few people, quickly had a first one-week meeting, a “sprint”, from where it evolved into a structure that was able to carry out a research project and got accepted by the European Union. During the course, two companies were founded. They are now growing and employing key developers. PyPy’s technical development is strongly rooted in open-source contexts and this adds another agility aspect free communication, co-operation and exchange with other people and projects. The process of obtaining EU-funding is a continous challenge to the community-rooted PyPy project; how to connect agile open source culture with formal structures, interaction with requirements like planning, budget estimation, work distribution and resource tracking. After our first “funded” year we are reasonably happy with the balance we strike between organisations and EU funding on the one and the developers driving the technical aspects of the project on the other side. 1 Agility in Technical Development and Organisation 1.1 Agile approaches: sprinting PyPy first started during a one-week meeting, a “sprint”, held at Trillke-Gut in Hildesheim February 2003. The sprint was inspired by practices used by other Python projects such as Zope3. Originally the sprint methodology used in the Python community grew from practices applied by the Zope Corporation. Their definition of a sprint was: “two-day or three-day focused development session, in which developers pair 1http://codespeak.net/pypy off together in a room and focus on building a particular subsystem”. Sprinting up to a week became the initial driving factor in developing the code base and the community/people around it. The early PyPy sprints were organised by core developers together with local Pythonistas in Louvain La Neuve, Gothenburg, Vilnius and Amsterdam. Sprints gave the opportunity to both help, participate and influence the ideas within PyPy. Sprints are actually not part of the traditional Agile portfolio of techniques, the closest thing to it comes from Scrum who names the 30 days long programming iterations “sprints”, covering a certain increment. With the Scrum method, considerable effort is put into performing the sprint planning as well as creating and documenting the “sprint backlog” which is then feedbacked into the “Product backlog”. The sprint ends with a “sprint review” an informal planning session in which the team decides on upcoming work. There are also techniques in which the team looks at ways to improve the development methodology and future sprints. To our knowledge, open-source projects these days are sprinting for at most a week which reflects the fact that many contributors give their time and even money to gather and work together. This is different from having fully funded people from one company working together. Why did PyPy choose sprinting as a key technique? It is a method that fits distributed teams well because it gets the team focused around visible challenging goals while working collarobatively (pair-programming, status meetings, discussions etc) as well as acceleratedly (short increments and tasks, “doing” and testing instead of long startups of planning and requirement gathering). This means that most of the time a sprint is a great way of getting results and getting new people aquainted a good method for dissemination of knowledge and learning within the team. A key insight, worthwhile for other EU-projects to ponder, is how an agile process like sprinting is much more suited for creative work between groups of dis-